\section*{Process}
\subsection*{Risk Assessment}
\input{risk-assessment.tex}

\subsection*{Project Schedule}
See updated SRS documentation.

\subsection*{Team structure}
See updated SRS documentation.

\subsection*{Test plan}
\begin{itemize*}
\item Unit Test Strategy
  \begin{itemize*}
  \item What this will test: This will test the functionality and
    correctness of each ``unit'' or module with regards to the
    specifications. The level of coverage will be our every module
    within our product. Although, not every aspect of each module will
    be tested as it is impossible to achieve 100\% coverage, we will
    test as much of each module as we possibly can within a reasonable
    time frame. The purpose of this test is to make sure that as
    individual parts, the modules work the way we specified them.
    This level of testing ensures us that when we go on to integrate
    them into a system, that the problem is more likely an integration
    issue rather than a module issue.
  \item How the test will be developed: We will develop and test the
    modules in two ways.  The first way will involve white box testing
    where we have each of the individuals who developed their module
    to develop tests that are tailored to the specifications and with
    the knowledge of the modules internal workings. This allows for
    more specialized testing in the way the programmer expected the
    module to be used.  Secondly we will have black box testing where
    we will assign different individuals to each module and have them
    test the module using only the knowledge they have from the
    specifications. This allows us to test against how a user would
    use our module.
  \item Frequency: Once we have developed a complete outline of all
    classes and methods and conditions, etc. we can start to develop
    test. We then can have these tests ran automatically (regression
    testing) or we can run them methodologically as jUnit tests as a
    majority of our code is in Java. We also plan to use the Hudson
    Continuous Integration system to help us with the building and
    testing at some point.
  \end{itemize*}
\end{itemize*}

\begin{itemize*}
\item System Test Strategy
  \begin{itemize*}
  \item \What this will test: This will test the functionality and
    correctness of the system when individual modules are connected
    and interact with each other. This testing will cover as many
    interactions as possible between modules. The purpose of a system
    test is to see if the system works as a whole. The individual
    modules may be correct within their own domain, but that does not
    necessarily mean they work together correctly. As such, this will
    help us discover flaws in the assumptions made about other modules
    when individual modules were made.

  \item How the test will be developed: The simplest way to test the
    system is to develop tests that will simply act as though it were
    a user and perform tasks that a normal user would do. We would
    simply give our UI input and have an expected behavior, and simply
    compare the results of the input with our expected behavior.

  \item Frequency: Once we have developed our modules, we will
    integrate them into a system and begin writing the tests. We will
    use the Hudson Continuous Integration also to have automated
    builds and automated testing. We currently have Hudson set up to
    do builds and tests every hour based on files currently in our
    repository.
  \end{itemize*}
\end{itemize*}

\begin{itemize*}
\item Usability Test Strategy
  \begin{itemize*}
  \item What this will test: As the name suggests, this strategy will
    test the usability of our product. The level of coverage will only
    include our Android UI and our Web UI. These are the parts that
    will be used be other individuals directly. The purpose is to make
    sure that performance, accuracy, and response of individual is
    what we what. We want to make sure that our product brings
    reasonable performance, such as time to do tasks, to the
    individuals using the product. We also want to make sure that our
    product is not confusing to the individual in such a way that they
    make mistakes. Finally, we want to make sure our product does not
    cause the user emotional distress or regular stress.
  \item How the test will be developed: The test requires almost no
    development. All we need is to grab people from anywhere
    (including hallways) and have them try out our product. If that
    doesn't work, we can recruit clients to test out our product and
    see if it is as usable as we think it is. This would be done in as
    many different environments as possible (browsers/OSs/etc).  We
    can basically do a cross-product of Windows/Linux and
    Chrome/Firefox/IE for the website and we'll have three different
    phones (along with an emulator) to test our Android application.
  \item Frequency: We will test the usability of our product as much
    as reasonably possible.  Generally we will want to test this after
    we make any major changes to the UI or internal structures that
    support the UI.
  \end{itemize*}
\end{itemize*}

\begin{itemize*}
\item Adequacy of Test Strategy
  \begin{itemize*}
  \item As many already know, it is impossible to discover all the
    bugs or problems within a program. The best we can do is find as
    many as we can and to fix the ones that are of highest risk to
    us. The listed test strategies are adequate in the sense that they
    cover the areas that need to be covered. We test each module
    individually to make sure that it does what we expect it to do,
    alone. We then integrate each module into a system that we can
    test to see if it follows the specifications we have
    drafted. Finally, we have individuals test out the usability of
    product to ensure that what we have made actually is usable to
    those who need it.
  \end{itemize*}
\end{itemize*}

\begin{itemize*}
\item Bug Tracking Mechanism and Plan of Use
  \begin{itemize*}
  \item Our bug tracking mechanism will be Google Code. Google code
    allows a person to create ``issues'' that everyone can see. We
    plan to create issues of bugs that we encounter along the
    implementation of the modules. The good thing about ``issues'' is
    that we can look at each issue and comment it, so the person
    implementing a module can get feedback on whether other users
    think the bug is significant problem. This allows us, as a team,
    to determine whether some bugs are worth fixing first. Not only
    that, but individuals who might be using our product can also
    leave issues as well.
  \end{itemize*}
\end{itemize*}

\subsection*{Documentation Plan}
The documents included with the software will be:
\begin{itemize*}
\item User manuals for both the web and android detailing all features
  and instructions on how to use each one
\item A web based FAQ
\item Code commenting with Javadoc generated files for future source
  modification and expansion
\item Administrative handbook for high level system maintenance
\item Quick start user guides for web and android
\end{itemize*}

\subsection*{Coding style guidelines}
\subsubsection*{Languages}
\begin{itemize*}
\item Java
  \begin{itemize*}
  \item See \href{http://geosoft.no/development/javastyle.html}{Style
      Guide}
  \item Note: basic indent should be 4.
  \item Eclipse: Window-$>$Preferences-$>$Java-$>$Code
    Style-$>$Formatter
    \begin{itemize*}
    \item Use New profile based on ``Java Conventions''
    \item Change ``Tab Policy'' to ``Spaces Only''
    \end{itemize*}
  \end{itemize*}
  
\item Clojure
  \begin{itemize*}
  \item \href{http://mumble.net/~campbell/scheme/style.txt}{Style
      Guide}
  \item Code should format exactly how Emacs enforces tabs.
  \end{itemize*}

\item Javascript
  \begin{itemize*}
  \item Must pass \href{http://www.jslint.com/}{JSLint}
  \end{itemize*}

\item HTML
  \begin{itemize*}
  \item Must pass \href{http://validator.w3.org/}{W3C HTML Validator}
  \item Ran through \href{http://infohound.net/tidy/}{HTML Tidy}
  \end{itemize*}

\item CSS
  \begin{itemize*}
  \item Must pass \href{http://jigsaw.w3.org/css-validator/}{W3C CSS
      Validator}
  \end{itemize*}

\item All Languages
  \begin{itemize*}
  \item Lines under 80 characters.
  \end{itemize*}
\end{itemize*}

\subsubsection*{Enforcement}
There are too many other pressing issues to deal with automatic
enforcement of these guidelines.  However, if any code that is found
to go grossly against these standards, there will be an immediate
issue attached to the source file.  The source can then no longer be
editted without first enforcing the standard style upon it first.
Thus, general team concensus on readability will be our periodic
checks on the guidelines.  Plus, during releases, the entire source
tree should be style checked by each owner before the publish.